Subject: Asymmetric COS mappings through Border Nodes

From: "Ray Bird" <[email-masked]>
Date: Fri, 1 Sep 95 14:36:27 EDT

An issue involving asymmetric COS mapping across Border Nodes and its effect
  on reusing RTP connections was raised at the AIW8 HPR SIG meeting.  Suppose
  an RTP connection between A (the origin that established the connection) and
  B (destination) traverses 3 subnets and the COSs are mapped COS1-COS2-COS3 (A
  uses COS1, B uses COS 3).  In the current HPR architecture, B may put new
  sessions using COS3 (and having the same path, etc.) on this existing RTP
  connection.  However, it might be the case that the COSs will be mapped dif-
  ferently from B to A (e.g., COS3-COS4-COS1 or COS3-COS4-COS5).  In this case,
  the reusing of the RTP connection by B for sessions with COS3 may not be the
  best thing to do.  The following are solutions are possible.

  SOLUTION 1: Allow an RTP connection to be reused only by the origin (A).  This
  works because the COSs are always mapped the same in the direction from the
  origin to the destination.  The drawback of this solution is that a second
  RTP connection must be established (by B) for BINDs going in the reverse
  direction (B to A) even though they are following the exact same path.  In other
  words, twice as many RTP connections are needed along with twice as much
  control block storage, timers, etc. at the RTP endpoints.

  SOLUTION 2 is to keep both the forward and reverse COS list (the complete
  list) associated with each RTP connection.  This has several drawbacks.

  o   The COS lists must be obtained for both directions (A to B and B to A).
      This is a fairly significant change to the Route Setup protocol.

  o   Both of the COS lists must be passed on Connection setup

  o   If B wants to reuse any RTP connection established by A, a Route Setup
      always needs to be done first to obtain the COS list to determine which
      RTP connection (if any) can be reused.

  SOLUTION 3 is to leave things as they are.
  The original intent of COS mappings across Border Nodes was that they
  would be symmetric in each direction.  This greatly simplifies things.  COS
  tables and Border Node COS mappings are complex enough already.  Asymmetric
  mappings make network management and debug ore difficult.  Lastly, it's not
  clear that there is a strong requirement from customers for asymmetric mappings.

  I recommend that, until requirements dictate otherwise, we leave things as
  they are and go with SOLUTION 3.

  Ray